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PATENT 



Attorney Docket No.: 16222U-012700US 

Client Reference No.: 3512 

METHOD AND SYSTEM FOR MANAGING LIMITED USE COUPON 

AND COUPON PRIORITIZATION 

CROSS-REFERENCES TO RELATED APPLICATION 
[0001] The present application claims the benefit of priority under 35 U.S.C. § 1 19 

from U.S. Provisional Patent Apphcation Serial No. 60/410,554, entitled "METHOD AND 
SYSTEM FOR MANAGING LIMITED USE COUPON AND COUPON 
PRIORITIZATION", filed on September 13, 2002, the disclosure of which is hereby 
incorporated by reference in its entirety for all purposes. 

BACKGROUND OF THE INVENTION 
[0002] The present invention generally relates to coupon redemption and, more 

specifically, to a method and system for managing coupon redemption and prioritization. 

[0003] Conventional, existing paper-based coupon systems do not provide any 

automated means to monitor and/or limit the nimiber of coupons that are redeemed by an 
individual or household. As a result, in situations where there are supposedly artificial limits 
on the number of coupons that can be redeemed by an individual or household, these limits 
cannot be effectively enforced. Due to the inability to monitor and limit the number of 
redeemable coupons, merchants or manufacturers sponsoring the coupons may suffer loss of 
revenues. 

[0004] Additionally, paper coupons present an obvious opportunity for fraudulent 

copying that can be mitigated only by serially numbering each coupon and recording the use 
of each coupon via an on-line, real-time system. Such preventive measures would 
significantly increase the cost of paper-based coupon systems and, thus, are rarely employed. 

[0005] Furthermore, existing smart card-based (and other card-based) loyalty systems 

also, in general, do not provide the means to limit coupon redemptions to a variable value 
determined by the coupon or reward program sponsor. Consequently, the coupon can only be 
redeemed once or an unlimited number of times. Each time a paper coupon or electronic 
reward is offered, the reward program sponsor need to determine the maximum cost 
associated with the redemption of such rewards in order to build a budget and business case 

1 



for launching the reward program. Additionally, the strategy to be employed by the reward 
sponsor will dictate whether a single use, unlimited use or a specified number of uses would 
best achieve the objectives of the rewards program. The inability to limit coupon 
redemptions therefore makes it exceptionally difficult to establish a realistic maximum 
5 budget to fund the rewards attributed to redeemed coupons since use is dictated not only by 
cardholder activation but also by frequency of use. 

[0006] Moreover, existing paper-based coupon and smart card-based loyalty systems 

do not provide any automated means to enforce rules associated with the combined 
redemption of coupons. Therefore, enforcement is generally performed manually (by reading 
10 the rules printed on each coupon) or enforcement is programmatically defined within the 
merchant's payment system application for each coupon that might be presented. Since the 
cost of continued updates to the merchant payment system would be prohibitive, redemption 
information is generally left to the clerk. 

[0007] Similar issues exist for the prioritization of redemption of multiple coupons 

15 associated with a single transaction. Although this might be handled programmatically, the 
variety of coupon types and the sheer volume of coupons that might be presented at the 
merchant register would make software maintenance extremely cost prohibitive. As a result, 
coupons are generally applied in the order received. 

[0008] Each reward (whether in the form of a paper coupon or an electronic program 

20 stored on a card or in a terminal) must be defined with a specific set of rules and legal 
restrictions in order to comply with legal requirements for disclosure to its potential 
recipients. Accordingly, those rules and legal restrictions must be enforced in order to insure 
that all recipients are receiving the same fair and impartial benefit. Therefore, rewards 
sponsors must define not only these rules but must also provide some level of assurance that 
25 the merchants that distribute the rewards can facilitate enforcement. Correspondingly, the 
rewards sponsor also establishes the rules in order to insure that the benefit derived by the 
recipient is consistent with the sponsor's business and financial plan and to insure that the 
reward creates an appropriate incentive for the consimier to perform the desired purchase 
behavior. Once electronic rewards are introduced, the challenges associated with rules 
30 enforcement become significantly more complex. 

[0009] Hence, it would be desirable to provide a method and system that is capable of 

efficiently managing coupon redemption and prioritization. 
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BRIEF SUMMARY OF THE INVENTION 
[0010] A system for managing coupon redemption and prioritization is provided. 

According to one exemplary aspect of the system, the system allows an electronic coupon or 
5 reward to be redeemed a specific nxmiber of times. The specific number of times may range 
from one to infinity. 

[0011] According to another exemplary aspect of the system, the system 

automatically resolves any redemption conflict associated with the concurrent redemption of 
electronic coupon(s) and paper-based coupon(s) by using certain predefined rules and logic. 

1 0 [0012] The present invention as described herein provides a number of benefits and 

advantages. For example, merchants would benefit from the use of the present invention 
since rules enforcement can be automated and applied at the token level. This reduces 
transaction time and the burden on clerks. Furthermore, the risk of coupon rejection by the 
program sponsor due to illegal and/or repeated use of a specific reward can be mitigated. 

IS [0013] Reference to the remaining portions of the specification, including the 

drawings and claims, will realize other features and advantages of the present invention. 
Further features and advantages of the present invention, as well as the structure and 
operation of various embodiments of the present invention, are described in detail below with 
respect to accompanying drawings, like reference numbers indicate identical or fimctionally 

20 similar elements. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0014] Fig. 1 is a simplified block diagram illustrating one exemplary embodiment of 

the present invention; 

25 [0015] Fig. 2 is a flow diagram illustrating the reward redemption process flow in 

accordance with an exemplary aspect of the present invention; 

[0016] Fig. 3 is a table showing an illustrative situation under which conflicts are 

resolved between paper-based and electronic coupons in accordance with an exemplary 
aspect of the present invention; and 
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[0017] Fig. 4 is a flow diagram illustrating the redemption conflict resolution process 

flow in accordance with an exemplary aspect of the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 
5 [0018] The present invention in the form of one or more exemplary embodiments will 

now be described. Fig. 1 is a simplified block diagram illustrating one exemplary 
embodiment of the present invention. According to this exemplary embodiment, the system 
10 includes a reward host 12, a merchant system 14, a number of card acceptance devices 
(CADs) 16 and a number of tokens 20. The reward host 12 is responsible for handling 

10 transactions generated by reward program participants. The reward host 12 is configured to 
communicate with the CADs 16 via the merchant system 14 thereby allowing reward 
transactions to be processed. The merchant system 14 further includes an open program 
engine (OPE) 18. The OPE 18 includes control logic that is used to control processing of a 
transaction under the reward program and facilitate communication between the reward host 

15 12 and the CADs 16. In one exemplary implementation, the OPE 18 is a card acceptance 
point device software module that interacts with the merchant system 14 to facilitate 
commxmications between the reward host 12 and the CADs 16. Alternatively, the 
functionality of the OPE 18 can be integrated into the merchant system 14. It should be 
further understood that, in alternative embodiments, the system 10 may include multiple 

20 merchant systems, each merchant system having its corresponding OPE and associated 
CADs. In other words, the reward host 12 is capable of handling coupon redemption and 
prioritization on multiple merchant systems. In an altemative exemplary embodiment, the 
OPE 18 can be implemented on a device coupled to the Internet. 

[0019] In one exemplary implementation, the reward host 12 is a computer server 

25 having a number of software applications. These software applications manage a list of 
reward program participants which are each uniquely identified and maintain information 
relating to different reward programs. As will be further described below, the reward host 12 
uses information relating to different reward programs to upload corresponding reward 
program parameters and other messages to each CAD 16. 

30 [0020] Each CAD 16 is equipped to receive and communicate with the token 20 

provided by a reward program participant. The token 20 contains, amongst other things, 
information that is specific to the reward program participant, such as, reward programs that 
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the participant is eligible to participate in and rewards accumulated in the corresponding 
reward programs. In one exemplary implementation, the token 20 is a smartcard. It should 
be understood that the token 20 includes other types of portable devices including, for 
example, a cellular phone, a personal digital assistant (PDA), a pager, a payment card (such 
5 as, a credit card and an ATM card), a security card, an access card, smart media, a 
transponder, and the like. 

[0021] Each CAD 16 is enabled with application software that provides device- 

specific functionality as well as the capability to interact with the reward host 12, to receive 
downloads of new reward programs and other security updates and to forward batched 

10 loyalty transactions back to the reward host 12 when appropriate. The application software 
also enables the CAD 16 to securely interact with the token 20 in a transaction to determine if 
the reward program participant has qualified for a specific reward and to facilitate both the 
eam process (addition of a reward benefit to the token) and the redemption process (utiUzing 
either a stored reward on the token or an electronic coupon). Preferably, the application 

15 software stores a limited quantity of transaction batches for delivery to the reward host 12. 
Furthermore, the application software also stores parameters for new loyalty or reward 
programs for current day or fiiture day activation. 

[0022] CADs 16 can be incorporated into or integrated with a number of different 

devices including, for example, smart card enabled point of sale terminals, kiosks, vending 
20 machines and electronic cash registers. In other exemplary embodiments, the CAD 16 can be 
any token acceptance devices that are capable of communicating with the token 20 including 
a point-of-sale device, a cellular phone, a personal digital assistant (PDA), a personal 
computer (PC), a tablet PC, a handheld specialized reader, a set-top box, an electronic cash 
register, a virtual cash register, a kiosk, a security system, an access system, and the like. 

25 [0023] According to one exemplary aspect of the system 10, the system 10 is able to 

monitor, manage and limit the number of times a reward or coupon can be redeemed on the 
token 20. The system 10 is also able to stop coupon accumulation once a redemption limit 
has been reached on the token 20. Furthermore, the system 10 allows a program 
administrator to set a limit to the number of times an immediate or delayed coupon or series 

30 of punches can be redeemed for a loyalty or reward program. 

[0024] In an exemplary embodiment, the system 10 includes a set of software 

components that allow a reward sponsor to determine or set the specific number of times 
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(e.g., from one (1) to unlimited) when the reward can be redeemed by a specific token 20 
during a specified time period of validity. This set of software components is distributed 
amongst the reward host 12, the CAD 16 and the token 20. 

[0025] One software component is an application that resides in or provides support 

5 to the CAD 16. This CAD application includes, among other reward specific elements, a 
variable field that can be set at the reward host 12 when the loyalty or reward program is 
originally defined and established. The variable field is a redemption limit parameter. The 
value of the redemption limit parameter represents the maximum number of times that the 
reward, once earned, can be redeemed. Alternatively, the redemption limit parameter can be 
10 stored in the OPE 18, The CAD 16 is capable of handling multiple reward programs. As a 
result, there may be multiple redemption limit parameters corresponding to the multiple 
reward programs. 

[0026] Another software component is within an applet stored on the token 20 (e.g., a 

smartcard or other portable device). This token component includes a dynamic data field that 
15 is updated each time the corresponding reward is redeemed. The dynamic data field is a 

redemption tally parameter. Similarly, since the token 20 may contain information relating to 
multiple reward programs that the reward program participant is eligible to participate in, the 
token 20 may also contain multiple corresponding redemption tally parameters. 

[0027] When the reward program participant performs a qualifying transaction under 

20 a selected reward program during the reward validity period, tiie CAD application queries the 
token 20 to obtain the value stored in the corresponding redemption tally parameter within 
the token component. This value is then compared to the value of the appropriate redemption 
limit parameter stored within the CAD application. If the value of the redemption tally 
parameter is equal to that of the redemption limit parameter, the reward is not applied to the 
25 transaction. If the value of the redemption tally parameter is zero or any value less than the 
value of the redemption limit parameter, the reward is applied to the transaction. 

[0028] Fig. 2 is a flow diagram illustrating the reward redemption process flow in 

accordance with an exemplary embodiment of the present invention. Referring to Fig. 2, at 
30, a program administrator who is responsible for managing the loyalty or reward program 
30 creates respective redemption limits for one or more rewards that are available under that 
reward program. The redemption limits can be based on a number of conditions, for 
example, the types of rewards or the identity of the reward program participants or a 



6 



combination of both. For instance, a certain type of reward may be designed to have a 
redemption limit that is different from other types of rewards, or reward program participants 
may be allowed to have varying corresponding redemption limits depending on qualifications 
of the reward program participants. Based on the disclosure and teachings provided herein, a 
5 person of ordinary skill in the art will appreciate how to design the appropriate redemption 
limits depending on the constraints and/or design of each reward program. In an exemplary 
implementation, the program administrator uses a user interface provided by the reward host 
12 to create the desired redemption limits. The redemption limits are then stored in the 
reward host 12. Furthermore, reward host 12 also allows the reward program sponsor to 
10 subsequently modify the desired redemption limits due to, for example, new conditions 
and/or changes to the reward program imposed by the reward program sponsor. 

[0029] At 32, the reward host 12 forwards information relating to the redemption 

limits to the appropriate OPEs 18. In an exemplary aspect, in order to optimize computing 
resources, the appropriate OPEs 18 are determined based on whether such OPEs 18 need to 
1 5 handle transactions for the particular reward program associated with the redemption limits. 
The information relating to the redemption limits is then subsequently used by the OPEs 18 
to control the reward redemption process. Since the redemption limits can be modified, the 
reward host 12 periodically forwards any modified redemption limit(s) to the appropriate 
OPEs 18. 

20 [0030] At 34, a reward program participant uses his/her token 20 to initiate a 

transaction with the CAD 16. A token image is retrieved by the CAD 16 from the token 20. 
The token image includes information about the reward program participant, such as, reward 
programs that the reward program participant is eligible for, rewards earned and rewards 
redeemed. Transaction details are also provided by the reward program participant to the 

25 CAD 16. For example, the reward program participant may indicate to the CAD 16 which 
reward program s/he wishes to apply to the transaction as well as the reward selected for 
redemption imder that reward program. In certain situations, the reward program may allow 
multiple rewards to be selected and applied to the transaction; in other situations, the 
transaction may qualify for redemption under multiple reward programs. 

30 [0031] At 36, the CAD 16, in turn, initiates processing of the transaction with the 

OPE 18. In an exemplary implementation, the token image and the transaction details are 
passed by the CAD 16 to the OPE 18 for processing. 
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[0032] At 38, the OPE 18 identifies the selected reward program and the 

corresponding selected reward that are to be apphed to the transaction and extracts the 
appropriate redemption tally parameter firom the token image and then compares it against the 
appropriate redemption hmit parameter that has been previously provided by the reward host 
12. 

[0033] At 40, if the OPE 18 determines that the redemption tally parameter is greater 

than or equal to the redemption limit parameter, then the selected reward program and the 
corresponding selected reward are not applied to the transaction. On the other hand, if 
redemption tally parameter is less than the redemption limit parameter, the transaction is 
processed according to the rules of the selected reward program. As part of the processing, 
the redemption tally parameter is incremented appropriately and the token image is updated 
to incorporate the latest reward program information relating to the reward program 
participant. 

[0034] At 42, the OPE 18 then forwards the updated token image to the CAD 16. At 

44, the CAD 16, in tum, updates the token 20 with the updated token image. At 46, once the 
token 20 successfully receives the updated token image, the token 20 forwards an 
acknowledgment to the CAD 16. At 48, upon receiving the acknowledgment, the CAD 16 
forwards a confirmation of the token update to the OPE 18. At 50, upon receiving the 
confirmation, the OPE 18 forwards the processed reward and transaction resuhs to the CAD 
16. At 52, the CAD 16 stores the processed reward and transaction results in a report queue 
or batch. Contents of the report queue or batch are periodically uploaded to the reward host 
12 for reporting and tabulation. 

[0035] It should be noted that the respective functionality performed by the CAD 1 6 

and the OPE 18 can be combined or distributed between the CAD 16 and the OPE 18 
depending on the various factors, such as, design and/or system constraints. For example, the 
redemption limit parameter can be stored in the CAD 16 as mentioned above, and the control 
logic for checking the redemption limit parameter against the redemption tally redemption 
can be implemented on the CAD 16 as well. Based on the disclosure and teachings provided 
herein, a person of ordinary skill in the art will know of other ways and/or methods to 
distribute the collective functionality of the CAD 16 and the OPE 18 in various different 
configurations in an integrated or modular manner. While the foregoing description 
illustrates a reward redemption process, it should be understood that the system as described 
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herein may also be used to monitor and control other aspects or processes relating to a 
reward. 

[0036] According to another exemplary aspect of the system 10, the system 10 is able 

to prioritize multiple coupon redemptions. The system 10 is able to resolve redemption 
5 conflicts between two or more rewards or coupons. The rules and logic used to resolve 

redemption conflicts are maintained by the system 10. For example, the system 10 is able to 
resolve redemption conflicts between a paper-based coupon and an electronic coupon, both of 
which are redeemable for the same reward, hi one illustrative situation, if an electronic 
coupon on the token 20 and a paper-based coupon of the same type (e.g. both are 
10 manufacturer or both are store coupons) are presented for redemption for the same SKU item 
during a single transaction, the paper-based coupon is redeemed first. Alternatively, the 
redemption order may be reversed depending on other constraints, such as, the rules specified 
by the reward program sponsor. 

[0037] If a paper-based coupon fi*om a manufacturer has been applied to a specific 

15 item, then the manufacturer's electronic coupon on the token 20 is not applied to the same 
item in the same transaction. Furthermore, loyalty or reward is delayed till the next 
transaction when manufacturers paper-based coupons and electronic coupons with identical 
product codes (e.g., SKU, bar code DPCI) are presented. Fig. 3 is a table showing the 
foregoing illustrative situation under which conflicts are resolved between paper-based and 
20 electronic coupons in accordance with one exemplary set of business rules of the present 
invention. 

[0038] In an exemplary embodiment, the system 10 includes a set of software 

components that allow a reward program sponsor to define the circumstances under which 
one or more electronic rewards or coupons stored on the token 20 (e.g. smartcard) can be 
25 applied and/or redeemed to a particular transaction when a paper-based coupon is also 
presented. It should also be noted that the system 10 includes devices that are capable of 
capturing information fi-om a paper-based coupon. Such devices include, for example, a bar 
code scanner or other similar types of devices. 

[0039] One software component is an application that resides in or provides support 

30 to the CAD 16. This CAD application 16 includes, among other reward specific elements, a 
data field that can be set at the reward host 12 when the loyalty or reward program is 
originally defined and established. This field represents the coupon type (e.g., manufacturer, 



9 



store^ etc.). Other priorities may be assigned to this coupon type field. The CAD application 
has control logic tiiat automatically allows or disallows the use of an electronic coupon when 
a reward program participant concurrently presents a paper-based coupon to be applied to the 
same purchase transaction. The coupon type field is used to indicate the source of the reward 
or discount being offered, whether in-store or manufacturer. The OPE 1 8 uses this 
information to allow taxes to be calculated correctly and enforce the redemption priority 
between paper-based coupons and electronic coupons. 

[0040] The coupon type field is optional. In one exemplary embodiment, the coupon 

type field is a one-byte flag and may have the following values: 

"NULL'* for "not specified"; 

"S" for "store"; 

"M" for "manufacturer"; and 

"O" for "other". 

If not used or required, the coupon type field can be set to space. 

[0041] Additional control logic within the CAD application defines the logical order 

(priority) in which paper-based coupons and electronic coupons are to be applied to the same 
purchase transaction, if either a paper-based coupon and an electronic coupon can be applied. 

[0042] The CAD application fiuther maintains other types of information relevant to 

the corresponding loyalty or reward programs. For example, the CAD application may 
maintain two fields, a store paper coupon quantity field and a manufacturer coupon quantity 
field. 

[0043] Data in the store paper coupon quantity field is sent fi^om the CAD 1 6 to the 

OPE 18 and is used to indicate which and how many items have already been used in store 
paper coupon redemptions. In one implementation, this field is a 3-digit numeric field and 
may have a value in the range between "0-999". A value of "0" means a store paper coupon 
was not redeemed against this item. 

[0044] Data in the manufacturer coupon quantity field is also sent firom the CAD 16 

to the OPE 18 and is used to indicate which and how many items have already been used in 
manufacturer paper coupon redemptions. In one implementation, this field is a 3-digit 
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numeric field and may have a value in the range between "0-999". A value of "0" means a 
manufacturer paper coupon was not redeemed against this item. 

[0045] Another software component is an application that is stored within the 

merchant payment sj^tem (e.g., electronic cash register, store controller, etc.). This 
5 application records the submission of paper-based coupons by type (e.g., manufacturer, store, 
etc.) as the reward program participant presents such coupons to the cashier for redemption. 
This application interacts with the CAD 16 and CAD application. 

[0046] When the reward program participant performs a qualifying transaction during 

the validity period of the electronic coupon and the reward program participant concurrently 

10 presents one or more paper coupons, the merchant payment system application queries the 
CAD application to determine if any electronic rewards can be applied to the transaction. If 
the CAD application determines that an electronic reward can be applied, the merchant 
payment system application then reads the list of paper-based coupons that have been 
presented with the transaction and determines if any of the paper-based coupons conflicts 

15 with any of the electronic coupons. For example, a conflict may occur because at least one 
paper-based coupon and one electronic coupon apply to the same product number. In the 
event a conflict is detected, the CAD application utilizes embedded logic to determine 
whether or not the electronic coupon should be applied in addition to the paper-based coupon. 
If it is determined that both the paper-based coupon and the electronic coupon can be applied, 

20 the CAD application informs the merchant payment system application of the value of the 
electronic coupon to be applied. On the other hand, if it is determined that there is a conflict 
between the paper-based coupon and the electronic coupon, the CAD application informs the 
merchant payment system accordingly and, if appropriate, stores the electronic coupon within 
the memory of the token 20 for future use by the reward program participant. 

25 [0047] Fig. 4 is a flow diagram illustrating the redemption conflict resolution process 

flow in accordance with an exemplary aspect of the present invention. Referring to Fig. 4, at 
60, the program administrator who is responsible for managing the loyalty or reward program 
creates respective redemption resolution rules for one or more rewards that are available 
under that reward program. The redemption resolution rules can be based on a nimiber of 

30 conditions. Based on the disclosure and teachings provided herein, a person of ordinary skill 
in the art will appreciate how to design the appropriate redemption resolution rules depending 
on the constraints and/or design of each reward program. In an exemplary implementation, 
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the program administrator \ises the user interface provided by the reward host 12 to create the 
desired redemption resolution rules. The redemption resolution rules are then stored in the 
reward host 12. Furthermore, the reward host 12 allows the reward program sponsor to 
subsequently modify the redemption resolution rules due to, for example, new conditions 
5 and/or changes to the reward program imposed by the reward program sponsor. 

[0048] At 62, the reward host 12 forwards information relating to the redemption 

resolution rules to the appropriate OPEs 18. In an exemplary aspect, in order to optimize 
computing resources, the appropriate OPEs 18 are determined based on whether such OPEs 
18 need to handle transactions for the particular reward program associated with the 
10 redemption resolution rules. The information relating to the redemption resolution rules is 
then subsequently used by the OPEs 18 to control the redemption resolution process. Since 
the redemption resolution rules can be modified, the reward host 12 periodically forwards any 
modified redemption resolution rule(s) to the appropriate OPEs 18. 

[0049] At 64, a reward program participant initiates a transaction using his/her token 

15 20 and at least one paper-based coupon. For example, the reward program participant 

presents his token 20 and the paper-based coupon to a clerk. In some situations, two or more 
paper-based coupons can be presented for redemption. 

[0050] At 66, the clerk scans the presented paper-based coupon into the CAD 16 

thereby allowing relevant information to be retrieved. The clerk also inserts the token 20 into 

20 the CAD 16 thereby allowing the token image to be retrieved by the CAD. The token image 
includes information about the reward program participant, such as, reward programs that the 
reward program participant is eligible for, electronic coupons representing rewards earned 
and available for redemption, and rewards redeemed. Transaction details may also be 
provided by the clerk to the CAD 16. For example, the clerk may indicate to the CAD 16 

25 which reward program the reward program participant wishes to apply to the transaction as 
well as the electronic coupon selected for redemption imder that reward program. In some 
situations, multiple electronic coupons may be selected for redemption. 

[0051] At 68, the CAD 16 initiates processing of the transaction with the OPE 18. In 

an exemplary implementation, the token image, information retrieved from the presented 
30 paper-based coupon(s) and the transaction details are passed by the CAD 16 to the OPE 18 
for processing. 
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[0052] At 70, the OPE 1 8 determines whether there is any conflict with the 

concurrent redemption of the selected electronic coupon and the presented paper-based 
coupon. If it is determined that there is a conflict, the OPE 1 8 uses the redemption resolution 
rules to resolve the conflict. For example, in one situation, if redemption of the electronic 
5 coupon and the paper-based coupon is mutually exclusive (as in a case where both the 

electronic coupon and the paper-based coupon are essentially the same reward offered by the 
same sponsor) and the paper-based coupon takes priority over the electronic coupon, then the 
redemption of the electronic coupon is deferred; in another situation, concurrent redemption 
of the electronic coupon and the paper-based coupon may be allowed ( as in a case where the 
10 electronic coupon is a manufacturer reward and the paper-based coupon is a store reward). 
Based on the disclosure and teachings provided herein, a person of ordinary skill in the art 
will appreciate how to resolve redemption conflict in various types of situations. 

[0053] At 72, the processing results are forwarded by the OPE 18 to the CAD 16. 

The CAD 16 may then display the processing results appropriately to the clerk and/or the 

15 reward program participant. For example, the CAD 16 may infomi the reward program 
participant that the previously selected electronic coupon has not been redeemed due to the 
redemption of the paper-based coupon, or vice versa. In addition, the CAD 16 may also 
update the token image of the token 20 based on the processing results. For example, if the 
previously selected electronic coupon is redeemed, the token image on the token 20 is 

20 updated to reflect such redemption. 

[0054] While the foregoing description illustrates a coupon prioritization process 

between a paper-based coupon and an electronic coupon, it should be understood that the 
system as described herein may also be used to handle coupon prioritization between other 
types of coupons. For example, the system 10 may be used to resolve redemption conflict 

25 between two paper-based coupons respectively offered by a manufacturer and a store. The 
present invention can also be extended to apply to other types of prioritization process 
between two electronic documents. For example, the present invention can be applied to 
manage the prioritization between a smartcard coupon and an electronic gift certificate 
represented by a discount number. Based on the disclosure and teachings provided herein, a 

30 person of ordinary skill in the art will know how to apply the present invention to other types 
of situations. 
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[0055] The system 10 as described above includes a number of software components. 

It should be understood that in addition to the configurations described above, the software 
components may be distributed in other manners, integrated or modular or otherwise, 
amongst the various components of the system 10 to achieve the same collective 
functionality, depending on factors such as the design and resource constraints of the system 
10. 

[0056] The system 10 as described above can be used and applied in many different 

situations. For example, the system 10 can be used with any smartcard-based loyalty 
program which stores loyalty data in distinct areas (slots) within a card applet and utilizes an 
intelligent software application within the CAD 16 and/or acceptance point payment system 
to perform logical calculations for the appUcation of rewards to purchase transactions. 

[0057] It is understood that the examples and embodiments described herein are for 

illustrative purposes only and that various modifications or changes in light thereof will be 
suggested to persons skilled in the art and are to be included within the spirit and purview of 
this application and scope of the appended claims. All pubUcations, patents, and patent 
applications cited herein are hereby incorporated by reference for all purposes in their 
entirety. 
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